page.waitForResponse 和 page.on('response', fn) 的资源开销对比

252

提炼

本文聚焦于 page.waitForResponse 和 page.on('response', fn) 在不同场景下从资源开销角度的优劣势分析。在面对不确定返回时间的单个响应时，两者资源占用相似，因都需 Promise 对象、超时定时器和事件监听器，且正确处理超时与监听器清理后无本质区别。而获取多个符合条件响应时，page.on('response', fn) 内存损耗低于 page.waitForResponse。page.on('response', fn) 可用一个 Promise 和监听器收集响应，特定条件满足时处理并移除监听器，资源开销固定；page.waitForResponse 为获取多个响应需多次调用或使用 Promise.all，每次都创建新 Promise 实例和监听器，获取 N 个响应就需 N 个 Promise 和监听器，内存与 CPU 开销更大。最后提到结合前文内容汇总成表格，辅助在不同场景选择合适监听器。

本文于 2025-10-02 22:31 首次发布，最后修改于 2025-10-02 22:32

在上一篇文章《 page.on('response',fn)的最佳实践之等待响应》中，我们为 page.on('response',fn) 封装了两个函数来分别达到“长时间情况下获取一个或多个响应”的目的。

理论上，封装的这两个函数是在变相的手动实现 page.waitForResponse 功能点。那么，在不同的场景下，我们又该如何选择使用它们呢？除了之前讨论的等待时间长短之外，今天，我们将从资源开销的角度来给出它们的优劣势。

首先，关于“获取单个响应”的资源占用

在面对一个不确定多久才会返回的响应时，`page.waitForResponse` 和 `page.on('response',fn) - 配合 Promise 和超时机制` 在资源占用方面是相似的。

因为，无论是哪种方法，为了等待一个可能很慢或永不返回的事件，都需要：

一个 Promise 对象来管理异步状态；
一个超时定时器来防止无限期等待；
一个事件监听器来等待事件触发；

所以，只要你正确地处理了超时和监听器的清理，这两种方法在等待单个响应时，资源占用并没有本质区别。

其次，关于“获取多个响应”的资源占用

当需要获取多个符合条件的响应时，page.on('response',fn) 模式的内存损耗比 page.waitForResponse 低。

page.on 模式：你可以用一个 Promise 和一个 page.on 监听器，来收集所有符合条件的响应。你只需要在满足特定条件（如收集到 5 个响应）时，一次性 resolve 这个 Promise，并移除监听器。这种模式的资源开销是固定的。
page.waitForResponse 模式：这个 API 的设计就是为了等待单个响应。如果要获取多个响应，你必须：
- 连续调用 await page.waitForResponse(...) 多次。
- 或者使用 Promise.all([page.waitForResponse(...), page.waitForResponse(...)])。

但，无论是 page.waitForResponse 的哪种方式，你每等待一个响应，都需要创建一个新的 Promise 实例和新的监听器。这就意味着，获取 N 个响应，你需要 N 个 Promise 和 N 个监听器。在短时间内创建和管理大量这些对象，其内存和 CPU 开销自然会比 page.on 的单实例模式更高。